問題の明確化 – 全体像

こんにちわ。組織開発がミッションの人事グループ・組織開発室に所属しているてぃーびーです。

利用者からのシステムへの問題提起。チームのふりかえりのミーティングで寄せられた仕事の進め方に関する問題提起。部門横断の活動に関わる問題提起。

仕事において、大小さまざまな問題が存在します。そして、誰かが問題提起をしてくれた場合、その問題の解決に向けてすぐに取り組むことがベストとは限りません。問題を解決していく前に、問題の明確化が必要なケースがあるためです。

この記事では、「問題の明確化」に関する全体像を説明します。

誰かが解決したほうがよいと考える問題があった場合、すぐに解決策の検討にとりかかることができる場合もあれば、事前に「問題の明確化」が必要なケースもあります。

典型的なパターンを図にすると以下のようになります。（以降、図を拡大してみたい場合は、図をクリックしてください）

そのうち、事前に「問題の明確化」が必要なケースは以下の部分です。

「問題提起」と「解決策」の内容に関するここまでの話は、システム開発における「ニーズ」と「実現方法」の関係に通ずるところがあります。

システムのニーズが曖昧な状態で提示されたり、ニーズが何かわからない状態で実現方法のみを提案されているとして、そのまま開発を開始しているような状態を想像してみてください。このようなことを繰り返していると、そのシステムは価値を生み出さないような機能で溢れかえってしまうことになりますし、本来は価値を生むために必要だった時間を浪費してしまうことになります。

極端な例を2つ考えてみると

のようなものです。これらと同じことが、問題の解決に関しても起こり得えるということです。システム開発において、このような選択肢をとるケースは少ないと思いますが、ひとたび開発外の問題を取り扱うとなると無意識にこれらの選択肢を選ぶということは珍しくありません。

不明確な問題には、大きく分けて2つのマイナス影響があります。

問題が不明確だと、問題に合わない解決策を選ぶ可能性が高まります。結果として、

という可能性があります。

問題が不明確だと、取り組む重要度が低い問題の解決に時間を使う可能性が高まります。結果として、

という可能性があります。

問題の明確化が必要な3つのケースに関する詳細は以下を確認ください。

「問題の明確化」に関する全体像を説明しました。

冒頭でも触れましたが、仕事には大小さまざまな問題が存在します。人によって取り扱う問題の大小は異なると思いますが、手順書に基づいた定型業務だけを担当しているのでなければ、多くの人は日常的に問題を取り扱うことになります。

問題の取り扱いについて、ふりかえる機会を用意し、明確化が必要な場面の判別と明確化の対応ができているか確認してみるとよいでしょう。